iT邦幫忙

2021 iThome 鐵人賽

DAY 6
0

找救援

意識到有問題時,首先尋找有沒有專案遇到同樣的問題——有使用 Ruby on Rails 的大規模專案不少,那為何不會浮現這些問題,代表我們肯定是有哪個環節需要修正,但每個專案的情境和需求都大相逕庭,因此沒有甚麼進展。

因緣際會下,同事麥可認識了領域驅動開發(Domain-Driven Design,後簡稱 DDD),並認為我們可以試著遵循裡面的原則套用在專案,理由有以下幾點:

  • 領域知識龐大,細節眾多
    單獨一人幾乎不可能掌握領域中所有的細節,而 DDD 可以專注在業務邏輯,並讓程式碼更容易被測試,使開發人員可以在短時間透過測試了解領域知識。
  • 需求一直在變
    DDD 可以讓程式更好的模組化,而更好的模組化代表開發時更彈性,有效應付持續變動的需求。
  • 領域知識複雜
    透過 DDD 的戰略設計可以使業務人員更好地理解自己的需求,並讓開發人員與業務人員有效的溝通,避免雞同鴨講。

決定要導入 DDD 後,首先是先整理目前的狀況

第一步

一開始我們先做了兩件事

  • 分析現有系統,並嘗試切割出不同領域
    我們先印出 DB 中的 er-diagram 和列出網站大致上的所有功能,接著嘗試把我們認為是同一個領域的 model 圈在一起,其中也會有出現不同領域共用同一個 model 的情況。

  • 在核心領域(core domain)中找尋共通語言與領域事件
    透過目前的程式碼和到處詢問相關部門的人員,收斂領域知識。這邊比較有系統的做法可以透過 事件風暴 (Event storming) 的方式來實踐。

    關於事件風暴可以看這系列的文章,有詳細的解釋
    Event Storming Part 1 - 簡介與事前準備

Q: 要怎麼知道這樣切割的領域是對的?

專案一開始如果視為一個大領域,不管怎麼切都可以減少需要關注的邏輯,因此對我們來說這樣的改動方向是對的。
當時我們的想法是,先透過既有程式碼和腦中舊有的知識大致規劃出一個雛形,這樣的切法肯定不會是最完美的,但至少能降低每個領域的複雜度,收斂各領域的知識並為其建立知識庫和測試,而有了測試,要再把領域切更細或是把多個領域合併成一個都會比較輕鬆。
除此之外,每個領域的設計其實會對應到我們對該領域的認識,而切分領域會使我們更專注在業務邏輯上,這也使我們更容易對領域去做更深的認識。
我認為切割領域是一種持續循環的調整,因此只需要滿足當前的需求就可以有效地解決問題,當新需求進來時,如果目前的設計導致開發成本過高,代表有新的領域知識,需要重新調整領域。

後記

一開始踏入 DDD 是透過閱讀 Eric Evans 所撰寫的領域驅動設計,老實說到現在仍有許多地方沒有理解的很透徹,直接閱讀本書會有許多新的觀點,但比較可惜的是這本書對如何實作 DDD 的方法著墨較少,所以後來都把這本書當作靈感書來使用,當有想不通的地方回去翻翻通常都會有新發現。


上一篇
[DAY5] 病識感──當我們關注到測試
下一篇
[DAY7] 手起刀落
系列文
在 Ruby on Rails 中導入 Domain-Driven Design 是不是搞錯了什麼?30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言